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Abstract 


The  purpose  of  the  research  was  to  explore  and  develop  a  set  of  principles  common  to 
rapid  acquisition  and  expedited  engineering  programs  utilizing  grounded  theory  and  qualitative 
research  methodologies.  To  accomplish  this  goal,  the  Systems  Engineering  Research  Council 
(SERC)  research  team  interviewed  over  30  organizations  from  across  the  DoD  which  focus  on 
less  traditional  acquisition  approaches  such  as  rapid  prototyping,  mature  technology  integration, 
or  extensive  platfonn  engineering.  A  set  of  standardized  questions  grouped  by  taxonomy  of 
people,  product,  and  process  was  used  to  guide  open  discussions.  The  responses  from  the 
interview  notes  were  analyzed  for  trends.  A  set  of  12  principles  were  identified  from  repeatedly 
emerging  concepts  in  the  systems  engineering  or  acquisition  processes  of  these  organizations. 
While  rapid  acquisition  offices  often  have  unique  attributes  and  pennissions,  these  principles 
may  be  applicable  to  traditional  acquisition  programs. 


1 
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Introduction 


General  Issue 

The  lifecycle  of  Joint  Urgent  Operational  Needs  (JUON)  programs  is  typically  driven  by 
“time  to  market”  constraints,  as  opposed  to  complete  satisfaction  of  a  static  set  of  program  or 
technical  requirements.  As  such,  product  or  capability  delivery  is  expected  in  days  or  months 
rather  than  the  typical  years  or  decades  for  a  traditional  acquisition  program.  A  recent  Defense 
Science  Board  (DSB)  Task  Force  identified  more  than  20  rapid-reaction  programs  and 
organizations  existing  to  address  DoD  urgent  warfighter  needs  (Defense  Science  Board,  2009). 

In  addition,  this  study  found  that  urgent-needs  programs  spent  more  than  $50  billion  between 
2005-2009,  and  urgent  needs  should  be  considered  a  critical,  ongoing  DoD  institutional 
capability.  A  subsequent  report  effectively  details  the  status  of  rapid  programs  today: 

“Over  the  past  decade,  each  military  service  and  the  Office  of  the  Secretary  of 
Defense  established  rapid  acquisition  activities  to  accommodate  these  [urgent  needs] 
situations.  In  fact,  more  than  20  such  organizations  exist  in  the  Department  today.  While 
many  urgent  needs  were  met  through  the  efforts  of  these  activities,  problematic  elements 
have  emerged.  Many  are  overstaffed,  yet  in  some  cases  without  sufficient  domain, 
technical  or  acquisition  experience.  There  are  logistics  and  sustainment  challenges  with 
these  capabilities  once  delivered  to  the  warfighter.  They  also  require  rapidly  available 
funds,  which  until  now  have  come  largely  from  supplemental  funding  to  the  defense 
budget.  Further,  there  are  no  comprehensive  plans  to  institutionalize  and/or  sunset  these 
many  rapid  acquisition  activities.  The  key  elements  to  rapidly  respond  to  unexpected 
operational  needs  include:  be  ‘schedule-driven’;  have  available  authority  and  funding;  be 
staffed  with  a  small  group  of  experienced  people;  and  have  full,  senior-level  support  for 
obtaining  necessary  waivers.  Each  Service  should  transition  to  a  single  rapid  acquisition 
organization  established  similarly  to  the  Air  Force  “Big  Safari”  program,  with  a  small, 
very  capable,  and  experienced  staff  of  20  -  50  people”  (Defense  Science  Board,  2011) 

Research  Focus 

The  Systems  Engineering  Research  Center  (SERC)  has  been  charged  with  investigating 
expedited  systems  engineering  and  rapid  acquisition  processes,  and  thus  created  a  project  to 
explore  these  concepts,  named  “Research  Task  (RT)  -  34”.  The  RT-34  research  examines  how 
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current  “rapid”  organizations  apply  acquisitions  and  engineering  methodologies  to  satisfy  urgent 
military  needs  developed  in  response  to  changing  threats.  RT-34  research  is  focused  on 
leveraging  currently  available  methods,  processes,  and  tools  to  create  an  expedited  systems 
engineering  framework  which  is  to  be  validated  in  practice.  Additional  RT-34  efforts  include  a 
specific  entrepreneurial  focused  review,  organizational  psychology  research,  software  modeling, 
and  product  family  definitions 

This  particular  research  effort  results  as  a  subset  of  the  RT-34  effort,  called  RT-34a.  The 
RT-34a  researchers  focused  on  data  collection  and  initial  analysis  of  the  organizational 
interviews.  This  analysis  is  to  document  the  state  of  the  current  rapid  acquisition  environment 
and  give  the  overall  RT-34  team  a  solid  foundation  for  development  of  an  applicable  framework 
and  design  of  experiment  for  future  application  in  the  field.  To  make  the  RT-34a  effort  useful  as 
a  standalone  product,  the  researchers  endeavored  to  create  a  “guidebook”  capturing  the 
fundamental  principles  of  rapid  acquisition  as  they  were  observed  through  the  research  process. 
The  results  will  be  combined  with  additional  products  and  analysis  from  RT-34  for  the 
application  phase  of  the  overall  research  task. 

Research  Question  and  Hypothesis 

The  research  question  of  this  study  was:  Is  there  a  common  set  of  practices  that  drive  the 
business  model  of  rapid  organizations?  The  hypothesis  of  RT-34a  is  that  rapid  acquisition 
processes  are  governed  by  a  common  set  of  principles.  Via  interview  sessions  with  these 
organizations,  the  expected  outcome  is  an  emergence  of  these  common  governance  principles. 
Potential  second  order  effects  are  that  expedited  SE  and  rapid  acquisition  concepts  could 
improve  processes  for  traditional  programs. 
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Methodology  and  Investigative  Questions 

The  research  team  set  out  to  discover  consistent  or  unique  attributes  of  rapid 
organizations.  How  do  these  organizations  field  military  capabilities  in  half  the  time  of  their 
traditional  counterparts?  What  makes  them  tick?  Is  there  a  "secret  sauce"?  Are  they  just 
breaking  all  the  rules?  Through  the  interview  processes,  a  list  of  questions  (see  Appendix  C) 
guided  open  discussions,  and  did  not  specifically  force  closed  responses  to  each  question.  The 
questions  generally  addressed  people,  process,  or  product  characteristics  of  the  rapid  acquisition 
efforts.  The  researchers  held  one  to  two  hour  conversations  with  each  organization  (ranging 
from  a  single  representative  to  a  small  group  of  senior  leaders)  and  did  not  focus  on  specific 
programs. 

The  method  in  this  research  is  based  on  grounded  theory.  Grounded  theory  is  a  type  of 
qualitative  research  methodology  that  allows  theories  to  emerge  from  the  collected  data.  This 
collection  of  data  comes  from  notes  during  interviews  with  the  leadership  of  these  “rapid” 
organizations — essentially  experts  in  the  field — to  discern  what  made  them  successful  and 
discover  what  drove  their  processes.  The  research  follows  a  systematic,  yet  flexible  process  to 
collect  data,  code  and  analyze  the  data,  make  connections,  and  see  what  theories  can  be 
generated.  This  "open  coding"  of  labels  is  an  important  part  of  the  analysis  concerned  with 
identifying,  naming  or  labeling,  categorizing,  and  describing  phenomena  found  in  the  interview 
notes.  In  this  case,  the  theory  is  a  set  of  principles  for  successful  rapid  acquisition. 

Limitations  and  Assumptions 

The  qualitative  nature  of  this  data  and  grounded  theory  research  allows  for  interpretation 
depending  on  the  readers  or  researchers  point  of  view.  Qualitative  analysis  can  therefore  become 
biased  based  on  individual  experience  and  perspective.  The  research  team  endeavored  to  stay 
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aware  of  bias  in  guiding  discussions  and  interpreting  data.  Further,  these  interviews  were 
conducted  as  guided  conversations  as  opposed  to  strict  survey  responses.  The  research  team 
ensured  the  topic  of  each  question  was  covered  within  the  course  of  each  conversation  and  felt 
better  data  was  acquired  by  allowing  the  interviewee  to  discuss  the  organization  and  its  processes 
in  their  own  way. 

While  the  RT-34  team  interviewed  over  30  organizations,  this  report  analyzed  data  from 
a  sub-set  of  the  interviews — covering  22  different  interviews  and  briefings.  Target  of 
opportunity  and  short  notice  interviews  afforded  great  openings  for  data  gathering,  but  not  all 
team  members  were  able  to  attend  all  interviews.  The  data  sets  used  for  this  research  (RT-34a) 
are  limited  to  those  personally  conducted  by  the  authors  or  those  with  which  they  have 
considerable  background  infonnation  to  provide  interview  context.  It  is  expected  the  full  dataset 
will  eventually  be  examined.  These  22  organizations  are  listed  in  Table  1.  The  names  of 
specific  commercial  companies  have  been  removed. 

Many  of  the  organizations  interviewed  were  managing  classified  programs  with  classified 
customers.  All  interviews  were  conducted  in  an  unclassified  environment.  This  may  have 
limited  the  extrema  of  detail  provided  and  potentially  prevented  full  disclosure  of  organizational 
practices.  Further,  this  precluded  detailed  discussions  on  specific  products  these  organizations 
have  delivered  or  are  developing  at  the  time  of  this  writing. 

It  is  an  underlying  assumption  that  the  organizations  interviewed  achieved  success  in 
some  right,  whether  that  be  cost,  schedule,  or  delivering  a  product  to  the  field.  Attempts  were 
not  made  to  explicitly  define  success  in  these  organizations,  but  rather  assume  that  by  their  very 
nature  and  existence,  they  are  successful  in  some  way. 
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Table  1.  List  of  Organizations  Interviewed 


Organization 

Date 

1 

American  Institute  of  Aeronautics  and  Astronautics  Space  Panel 

28  Sep  1 1 

2 

Technology  design,  R&D,  consulting  firm 

28  Sep  1 1 

3 

An  aerospace  industry  futures  lab 

28  Sep  1 1 

4 

A  rocket  engine  design  company 

30  Sep  1 1 

5 

Annual  SERC  Research  Review  (multiple  presentations  and  interviews) 

5  Oct  1 1 

6 

European  satellite  development  company 

10  Oct  11 

7 

NASA  Goddard  Space  Flight  Center 

12  Oct  11 

8 

Joint  Operationally  Responsive  Space  Office 

17  Oct  11 

9 

USAF  Space  Development  and  Test  Directorate 

18  Oct  11 

10 

Air  Force  Rapid  Capabilities  Office  (RCO) 

7  Nov  1 1 

11 

National  Reconnaissance  Office  (NRO) 

16  Nov  1 1 

12 

Academic  institution 

12  Dec  11 

13 

U.S.  Army  Product  Integration  Facility  (PIF) 

13  Dec  11 

14 

Engineering,  applied  science,  and  information  technology  company 

13  Dec  11 

15 

Big  Safari  (USAF  Program  Executive  Office,  ISR-SOF) 

13  Feb  12 

16 

Air  Force  Research  Lab(AFRL)  Center  for  Rapid  Product  Development 

13  Feb  12 

17 

Aeronautical  Systems  Center,  Rapid  Development  Integration  Facility  (RDIF) 

13  Feb  12 

18 

AFRL  Air  Vehicles  Directorate 

13  Feb  12 

19 

Air  Force  Space  Command  /  A5 

12  Mar  12 

20 

Space  and  Missile  Systems  Center,  Rapid  Reaction  Branch 

13  Mar  12 

21 

Air  Force  Tactical  Exploitation  of  National  Capabilities  (TENCAP) 

13  Mar  12 

22 

Space  and  Missile  Systems  Center  HQ 

14  Mar  12 

Finally,  it  is  also  important  to  note  the  data  collected  in  these  interviews  is  the  foundation 
for  the  principles  presented.  However,  based  on  requests  from  most  of  these  organizations — and 
at  times  the  condition  of  the  conversation  with  them — we  do  not  relate  statements  or  anecdotes 
with  specific  personnel  or  organizations  this  presentation  of  the  data. 

Implications 

This  guidebook  is  the  first  result  of  the  RT-34  research.  It  is  intended  for  a  general 
acquisition  and  engineering  audience  as  an  avenue  of  discussing  the  “business  model”  of  rapid 
organizations.  The  successful  techniques  seen  in  rapid  organizations  are  potentially  applicable 
and  scalable  to  more  complex  and  long-standing  weapon  system  development  programs. 
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The  Guidebook 


This  guidebook  provides  insights  into  the  consistently  recurring  characteristics  of  rapid 
organizations.  Through  analysis  of  the  data  emerged  12  “principles”  of  rapid  acquisition  and 
expedited  systems  engineering  (SE).  These  principles  could  also  be  called  “habits”,  “tenants”,  or 
“heuristics”.  Whatever  the  name,  RT-34a  research  shows  these  12  principles  as  the  driving  and 
defining  behaviors  of  these  organizations.  These  principles  are  organized  into  three  categories; 
people,  process,  and  product.  Each  grouping  of  principles  is  centered  on  these  categories, 
defined  as  follows: 

People  -  (the  who)  -  The  characteristics,  knowledge,  education,  and  behaviors  of  the 
personnel  in  these  organizations. 

Process  -  (the  how  and  where)  -  Describes  key  programmatic  and  system  engineering 
strategies  used  to  successfully  execute  rapid  product  development. 

Product  -  (the  what  and  why)  -  Defines  conceptual  use  of  technology  used  to  meet  the 
operational  needs  of  warfighters. 

The  principles  of  rapid  acquisition  and  expedited  SE  are  listed  and  discussed  in  a 
numbered  sequence;  however  no  single  principle  is  necessarily  more  important  than  another. 
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PEOPLE 


Principle  1:  Build  and  Maintain  Trust 
Principle  2:  Populate  Your  Team  with  Specific  Skills  and  Experience 
Principle  3:  Maintain  High  Levels  of  Motivation  and  Expectations 
Principle  4:  The  Government  Team  Leads  the  Way 


Principle  1:  Build  and  Maintain  Trust 

•  Develop  solid  relationships  and  work  to  maintain  them 

•  Empowered  leadership 

•  Autonomy  for  Program  Managers/Engineers 

•  Consistent  customer  input  &  buy-in  every  step  of  the  way 

Building  and  maintaining  trust  enables  empowered  teams  working  together,  being 
allowed  to  make  decisions,  leaders  standing  behind  their  decisions,  and  dealing  with  success  or 
failures  as  they  are  encountered.  This  building  process  is  a  struggle  at  times  and  may  even 
involve  internal  and  external  conflicts.  These  conflicts  must  be  enriching  experiences, 
opportunities  to  leam,  grow,  cooperate,  and  move  forward. 

Interviews  repeatedly  showed  leadership  at  all  levels  providing  top  cover  to  allow  teams 
to  focus  on  executing  the  mission.  These  same  leaders  must  be  empowered  and  trusted  at  the 
lowest  level  possible  to  make  tactical  and  strategic  decisions.  When  decision  making  authority  is 
placed  at  a  low  level  it  shortens  the  process,  reduces  opportunity  for  stall  time,  and  fosters  close 
relationships. 

Most  interviews  conducted  circled  back  to  strong  relationships  with  the  customer.  From 
this  perspective,  it  was  vital  to  have  the  customer  consistently  involved  in  the  decision  making 
process  and  to  gather  their  feedback  as  the  process  moved  forward.  This  was  accomplished  in 
many  different  ways:  Short-  and/or  long-tenn  on  site  customer  representatives,  customer  input 
and  regular  conversations  through  reviews,  or  simply  a  close  relationship  and  coordination 
process.  Regardless  of  how  the  customer  was  included  on  the  team,  it  was  clear  that  trust  in  the 
team’s  ability  to  deliver  was  vital  to  project  success. 
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Trust  is  built  through  expertise,  show  of  confidence,  and  record  of  perfonnance.  On  the 
outside,  it  appears  relationships  exist  on  an  organizational  level.  However,  interviews  showed 
building  and  maintaining  trust  within  a  program  team  required  constant  nurturing.  Further, 
trusting  relationships  showed  just  as  important  between  individuals  within  these  teams  as 
building  and  maintaining  trust  with  customers  and  senior  leaders.  It  was  consistently 
demonstrated  that  personal  trust  relationships  at  every  level  built  foundations  for  organization 
reputation  and  credibility.  In  addition,  the  existence  of  a  trust  network  appeared  important  for 
developing  connections  inside  and  outside  the  organizations.  Further,  personal  trust  networks 
became  intertwined  -  enhancing  and  extending  the  capabilities  and  connections  between 
organizations.  This  helps  quickly  build  trust  by  leveraging  pre-existing  and  proven  relationships 
to  build  new  ones. 

Individuals  build  trust  with  one  another  through  demonstrated  commitment  and 
competence.  A  successful  acquisition  team  must  have  highly  skilled  acquisition  professionals. 
But  it  is  only  through  the  consistent  application  of  those  skills  that  trust  is  built  with  leadership 
and  individual  or  organizational  autonomy  is  granted.  Thus,  not  only  must  the  desire  to  grant 
autonomy  or  empowerment  exist  in  the  leader,  it  must  be  earned  by  those  at  the  lower  level.  It  is 
on  the  back  of  established  trust  relationships  with  senior  leadership  and  the  customer  that  this 
autonomy  allows  small  teams  to  rapidly  move  programs  forward. 

Principle  2:  Populate  Your  Team  with  Specific  Skills  and  Experience 

•  Hand  pick  your  team. . . or  grow  your  own 

•  Acquire  people  with  the  right  education,  experience,  and  personality 

•  Build  the  right  team  for  each  project 

Interview  data  alluded  to  hand  picking  teams  and  developing  specific  skill  sets  as  a  key 
aspect  of  success.  Data  indicated  over  90%  of  the  interviewed  organizations  handpicked  their 
staff.  Organizations  identified  required  skills  needed  for  each  project  and  took  necessary  actions 
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to  acquire  that  skill  set.  Several  methods  of  acquiring  these  skill  sets  were  used:  handpick  new 
individuals,  grow/groom  current  personnel,  hire  contractor  support,  and  reorganize  teams.  For 
these  organizations,  these  vital  individuals,  either  of  their  own  accord  or  external  grooming, 
become  experts  with  very  specific  skill  sets  and  experiences.  These  individuals  can  then  apply 
their  skill  sets  to  projects  with  specific  customers,  technologies  or  operational  contexts. 

Several  senior  leaders  interviewed  brought  focus  to  expertise  by  indicating  that  a  vital 
trait  of  aggressive  DoD  acquisition  involves  acute  proficiency  and  depth  concerning  the 
application  of  the  so-called  “normal”  acquisition  process.  In  order  to  tailor  the  applicable  rules  of 
acquisition  and  engineering,  team  members  must  first  understand  what  the  rules  are  and  which 
rules  or  processes  apply  to  the  situation.  People  with  deep  roots  and  experience  in  acquisitions, 
contracting,  finance  and  engineering  know  what  the  standard  processes  are.  They  have  executed 
large  and  small  projects  using  various  methods  and  standards.  Thus,  they  are  keenly  aware  of 
the  implications  from  omitting  a  step  or  the  challenges  in  executing  parallel  development 
processes.  Their  expert  knowledge  of  the  proper  process  allows  them  to  create  a  process 
specifically  designed  to  meet  the  needs  of  their  program. 

One  particular  organization  interviewed  was  not  100%  selectively  manned.  As 
leadership  detennines  not  only  the  technical  strengths  of  the  team,  but  the  activities  that  bring 
staff  personal  reward,  organizations  can  re-evaluate  their  internal  structure.  When  asked  how 
they  organized  the  team  to  account  for  this,  they  stated,  “We  evaluate  our  team  by  the  strengths 
and  skill  sets  we  are  given.  If  we  have  to  reorganize  a  flight  to  meet  the  skill  set  of  the  team  we 
have,  we  do  it.  Finding  out  what  a  team  member  enjoys  and  is  good  at  and  letting  them  work  in 
that  area  all  but  makes  up  for  lack  of  ‘handpicking’  every  member.”  In  some  cases,  a  person 
with  the  right  attitude,  personality,  or  motivation  can  make  up  for  a  lack  of  technical  skill  or 
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experience.  In  other  words,  this  organization  was  able  to  make  up  for  a  specific  lack  of 
knowledge  and  skill,  by  strategically  leveraging  the  strengths  of  the  personnel  they  had — even  if 
that  meant  moving  personnel  around  as  projects  progressed  through  the  organization. 

Besides  the  desire  to  hand  select  personnel,  most  of  these  organizations  required  a  long 
tenn  commitment,  particularly  for  military  personnel.  Instead  of  the  typical  two  year  job 
rotation,  military  members  are  on  three  to  four-year  controlled  tours — only  released  for 
command,  Professional  Military  Education  opportunities,  or  other  unique  situations. 
Organizations  cited  a  desire  to  keep  good  talent  as  long  as  possible,  and  influence  on-the-job 
experience  as  individuals  grew  in  their  ability  to  execute  organizational  processes. 

Principle  3:  Maintain  High  Levels  of  Motivation  and  Expectations 

•  Motivation  and  mindset:  Collaborative,  competitive,  impatient,  creative,  technical,  tangible 
results,  independent 

•  Mistakes  are  OK,  but  it  is  not  OK  to  repeat  them 

•  Every  member  connected  to  the  mission  and  vision 

As  the  research  team  interviewed  these  organizations,  a  certain  enthusiasm  was  noticed 
abounding  in  the  leaders  and  personnel — seeming  to  share  a  state  of  mind  that  was  somehow 
traditionally  military  and  entrepreneurial  in  spirit.  The  mindset  of  these  individuals  expressed  a 
competitive  nature  bom  from  a  unique  skill  set,  an  aggressive  and  competitive  environment,  and 
a  tangible  connection  to  helping  accomplish  an  operational  mission.  They  are  motivated. 

Through  discussion,  this  motivation  appears  to  emanate  from  three  primary  sources. 

First,  there  is  a  direct  connection  to  an  operational  community.  Working  closely  with  the  end 
users  creates  both  a  connection  to  the  operational  task  at  hand  and  puts  a  face  on  the  customer. 
The  team  is  not  just  rushing  to  develop  an  oxygen  sensor  for  F-22  pilots;  they  are  developing  it 
for  Capt  Josh  “Tread”  Saufley,  so  he  avoids  getting  hypoxic  on  his  next  flight.  Second,  there  is  a 
sense  of  urgency.  JUONs  by  their  nature  are  “urgent”  and  of  critical  importance.  Providing 


14 


capability  to  the  field  may  very  well  be  a  matter  of  survival  and  mission  success  for  US  military 
members.  Finally,  the  rapid  nature  of  these  projects  provides  a  tangible  result  not  typically 
experienced  by  members  of  the  acquisition  and  engineering  community.  Members  of  the  rapid 
acquisition  community  have  the  opportunity  to  see  a  project  from  concept  definition,  through 
development,  and  launch  it  into  operational  use.  This  concrete  effect  of  seeing  the  fruits  of  labor 
utilized  by  its  intended  customer  can  be  very  powerful  and  help  maintain  sustained  levels  of 
motivation— even  through  long  and  arduous  workdays. 

A  unique  environmental  characteristic  observed  in  several  organizations  was  one  in 
which  mistakes  are  OK,  but  not  OK  to  be  repeated.  This  concept  is  vital  to  fostering  a  creative, 
collaborative,  and  yet  competitive  environment.  One  specific  technique  observed  to  hone 
organizational  skills  is  a  “debrief  culture”.  Originating  from  the  operational  world  of  reviewing 
a  mission,  focused  debriefs  on  team  perfonnance  can  be  extremely  powerful.  A  debrief  culture 
emphasizes  learning  from  mistakes  and  works  to  identify  root  causes  (individual  or 
organizational)  to  improve  future  endeavors.  Furthermore,  the  debrief  process  may  be  applied  to 
iterations  or  phases  of  current  projects  in  addition  to  a  final  project  debrief.  The  purpose  of  a 
focused  debrief  is  to  determine  what  went  wrong  and  develop  “lessons  learned”  (much  like  a 
detailed  heuristic)  to  prevent  the  same  errors  from  occurring  in  the  next  project  or  subsequent 
iterations  of  the  current  project. 

The  debrief  culture  must  be  established  at  the  top  level  of  the  organization  where  leaders 
outline  and  enforce  the  expectations  and  importance  of  the  debrief  process.  A  successful  debrief 
methodology  centers  on  developing  focus  points  derived  from  the  comparison  of  the  project’s 
intended  objectives  and  the  actual  outcome,  and  then  investigating  to  detennine  the  root  causes 
of  the  focus  points.  To  clearly  maintain  motivation  and  expectations  inside  an  organization,  each 
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member  needs  to  expect  that  a  thorough  debrief  will  be  conducted  with  the  overall  goal  of 
identifying  the  underlying  cause  of  any  less-than-perfect  outcomes.  More  details  on  this  process 
are  explained  in  Appendix  A. 

Principle  4:  The  Government  Team  Leads  the  Way 

•  High  level  of  expectations  for  government  personnel  (military  and  civilian)  to  run  programs 

•  Focus  on  full  use  of  government  personnel  capabilities  -  technical  competence  is  expected 

Rapid  organizations  work  hard  to  find  and  hire  military  and  government  experts. 
Government  personnel  are  expected  to  run  the  programs,  often  times  without  a  prime  contractor 
or  support  contractors  as  part  of  the  organization.  Many  of  the  rapid  programs  interviewed  had  a 
small  support  contractor  footprint,  if  at  all— compared  to  most  major  acquisition  programs.  This 
is  not  to  say  they  did  not  employ  or  rely  on  contractors  to  provide  leadership  or  technical  support 
on  a  large  or  small  scale.  However,  when  programs  did  have  a  support  contractor  workforce,  the 
expectation  was  still  the  same:  The  government  engineer,  program  manager,  operations 
representative,  etc.,  was  expected  to  be  the  resident  expert  on  the  program. 

These  government  teams  are  typically  comprised  of  a  set  of  functional  experts  as  a 
development  team.  Core  capabilities  will  exist  on  these  teams  -  a  program  acquisition  officer, 
resource/financial  manager,  system  engineer,  operational  expert,  safety,  and  test  personnel. 
Technical  competence  is  the  standard,  not  the  exception.  It  is  expected  every  member  of  the 
team  is  technically  able  to  run  their  portion  of  the  program.  They  maintain  awareness  of 
activities  and  issues  on  all  aspects  of  the  development  program,  regardless  of  government  or 
contractor  responsibility.  There  is  little  room  for  redundancy. 

In  conversation  with  a  Chief  Engineer  from  a  large  program  office  at  SMC,  the  following 
interaction  was  recounted:  At  a  weekly  internal  program  review  several  support  contractors 
were  briefing  status  with  a  handful  of  Lieutenants  and  Captains  sitting  silent  around  the  room. 
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One  month  into  the  job  he  asked  the  support  contractors  to  hold  their  concerns  and  asked  the 
Captains  to  brief.  They  could  not.  His  question  back  to  them  was,  “Why  are  you  here?” 
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Principle  5:  Defined  Set  of  Stable  Requirements  Focused  on  Warfighter  Needs 
Principle  6:  Small  Co-Located  Teams 
Principle  7:  Document  to  Capture  the  Intent  of  DoD  5000.2 
Principle  8:  Designing  out  All  Risk  Takes  Forever... Accept  Some  Risk  of  Failure 
Principle  9:  Keep  an  eye  on  Normalization 


Principle  5:  Defined  Set  of  Stable  Requirements  Focused  on  Warfighter  Needs 

•  Get  the  requirements  right— everything  you  do  stems  from  them! 

•  Capability  based  requirements  rooted  in  customer  derived  “CONOPS” 

•  Use  solid  systems  engineering  (SE) 

•  Expedite  trade  studies  -  then  make  a  decision  and  press  forward 

•  Focus  on  providing  the  23-80%  solution 

Defining  stable  requirements  focused  on  the  customer  needs  was  one  of  the  most 
frequently  occurring  principles  during  the  interviews.  Not  only  is  there  not  enough  time  to  do 
everything  a  customer  is  asking  for,  but  customers  often  ask  for  more  than  they  really  need  to 
meet  their  operational  objectives.  It  quickly  became  evident  through  the  interviews,  that  every 
one  of  these  organizations  spends  a  significant  amount  of  time  up-front,  face-to-face  with  their 
customer  discussing  requirements  and  operational  context.  They  may  actually  spend  more  time 
hashing  out  a  solid  set  of  requirements  than  they  do  in  actual  design  and  production. 

Our  interviews  brought  to  light  several  frustrations  of  the  requirements  development 
process.  Customer  disconnects  or  unrealistic  expectations  may  emerge  because  customers  are 
unaware  of  the  state-of-the-possible.  Customers  may  not  understand  how  difficult  it  might  be  to 
accomplish  their  requests.  Occasionally,  a  customer  may  have  observed  a  system  used  by 
another  entity  and  think  “I  need  one  of  those” — seeing  a  product  versus  indentifying  a  specific 
capability.  In  response,  the  rapid  organizations  are  deeply  rooted  in  a  capability  based  approach 
to  requirements  analysis.  This  drives  concepts  of  operations  based  analysis,  where  the  customer 
must  clearly  define  specific  needs,  uses,  or  capabilities  for  the  system — in  an  operational  context. 
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Equally  important  is  an  effort  to  keep  the  requirements  stable.  Irrespective  of  the  scope 
of  a  project,  requirements  creep  will  negatively  impact  the  timeline  of  a  project,  delaying  the 
delivery  of  operational  capabilities  to  the  warfighter.  Further,  requirement  changes  potentially 
weaken  the  scope  of  the  project  or  may  negate  any  perceived  increase  in  baseline  capability.  As  a 
tenant  for  rapid  SE,  stabilizing  requirements  starts  with  ensuring  the  requirements  are  right — in 
other  words,  directly  interacting  with  the  customer  to  detennine  what  the  paramount  needs  are 
rather  then  satisfying  all-inclusive  wants.  Organizations  that  consistently  execute  rapid  SE  and 
acquisitions  are  rooted  in  high-quality  requirements.  In  essence,  rapid  acquisition  requires  stable 
requirements. 

Rapid  organizations  validate  requirements  early  and  often  with  the  customer  to  determine 
needs  based  on  capabilities.  The  acquiring  organization  must  be  willing  to  push  back  against 
unfeasible  requirements,  or  schedule  impacting  requirements,  in  the  interest  of  time.  As  one 
senior  officer  explained,  “[The  organization  must]  fight  hard  to  have  the  warfighter  make  trades” 
to  establish  requirements  that  are  possible  in  the  desired  timeframe.  Simply  put,  focus  on  valid 
requirements  that  can  be  met  by  the  state  of  the  possible  in  a  short  amount  of  time. 

The  application  of  solid  SE  principles  during  early  requirements  definition  promotes 
unambiguous  and  achievable  requirements.  SE  ideologies  emphasize  relating  requirements  to 
specific  design  criteria  and  ensuring  the  traceability  of  those  requirements  from  the  system-level 
downward.  Through  an  interactive  process  with  the  customer,  the  focus  should  be  on  concept 
refinement,  defining  the  system  trade-space,  developing  system-level  and  derived  requirements, 
making  appropriate  system-level  tradeoff  decisions  and  critically  searching  for  problems  and 
disconnects.  Applying  these  concepts  at  the  beginning  of  the  project  (and  iteratively  throughout) 
can  foster  achievable  objectives  with  reduced  late-in-phase  design  effort. 
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The  short  duration  of  rapid  acquisition  projects  naturally  lends  to  more  stability  in 
requirements.  First,  grand  changes  in  technical  maturity  or  capability  are  not  often  experienced 
in  the  lifecycle  of  the  project.  Second,  there  are  fewer  changes  in  political  administration 
(funding),  leadership  (rotating  Colonels)  and  program  personnel;  each  personality  bringing  to  the 
project  a  new  perspective  or  priority  than  their  predecessor.  Finally,  the  requirements  stemming 
directly  from  urgent  warfighter  needs  are  less  likely  to  change  over  the  short  period  of  time. 

Ironically,  requirements  creep  can  become  a  pitfall  of  regular  customer  involvement  in 
requirements  refinement.  Several  organizations  emphasized  the  necessity  to  fight  requirements 
creep  once  stable  requirements  have  been  established.  However,  stopping  creep  cannot  be  done 
at  the  expense  of  customer  and  user  involvement.  In  this  manner,  an  art  must  be  developed  to 
keep  the  user  in  the  loop  without  allowing  for  spurious  changes  to  the  project  once  underway.  A 
chief  task  for  the  Systems  Engineer  should  be  persistent  analysis  of  derived  requirements  in 
conjunction  with  making  difficult  decisions  regarding  system  requirement  trades  and  concept 
refinement. 

Rapid  programs  rarely  provide  the  customer  with  100%  of  what  they  ask  for. 

Interviewees  expressed  the  typical  “80%  solution”  concept,  but  also  a  more  realistic  (albeit 
academic  in  number)  “23%  solution”  in  practice.  By  framing  the  question  to  the  customer  as 
“Instead  of  XX  in  10  years,  I  can  give  you  XY  in  a  few,”  the  user  may  be  more  inclined  to  agree. 
One  interview  with  a  space  focused  organization  responded  “50%  or  23%  done  quickly  can  be 
very  acceptable.”  Often  eliminating  or  modifying  certain  requirements  will  provide  the 
warfighter  with  a  viable  solution  to  a  problem  within  an  expedited,  achievable  timeline  rather 
than  a  never-ending  pursuit  of  the  100%  solution. 
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The  requirements  process  often  boils  down  to  the  program  team  getting  the  customer  to 
clearly  articulate  exactly  what  capabilities  they  need  in  the  field.  Just  as  critically,  these 
conversations  and  research  by  the  development  team  help  the  customer  understand  the 
perfonnance  and  schedule  risk  of  pushing  the  state-of-the  art  too  far.  Clearly  understanding  the 
capabilities  of  industry  and  current  technology  significantly  improves  customer  expectations  of 
what  can  be  accomplished  in  a  short  amount  of  time.  This  then  shapes  the  product  design  space. 
Then,  after  some  quick  analysis,  the  program  team  can  say,  “A  100%  solution  will  take  4  years. 
However,  I  can  get  40%  of  what  you  want  in  about  9  months  and  it  will  do  X,  Y  and  Z.  Will  that 
work?”  The  answer  is  often  an  enthusiastic  “yes”.  In  this  environment,  an  organization  can  be 
seen  as  heroic  for  being  able  to  provide  a  solution  that  does  two  or  three  things  really  well, 
delivered  in  a  short  amount  of  time;  rather  than  providing  the  warfighter  a  system  that  can  do 
those  same  three  things  and  assumedly  several  others  after  five  years  (or  more). 

Principle  6:  Small  Co-Located  Teams 

•  Small  teams  with  the  right  skill  sets  to  solve  the  problem 

•  Co-located  workspace  and  facilities 

As  the  research  explored  the  characteristics  of  the  people  of  these  rapid  focused 
organizations,  a  consistent  organizational  pattern  materialized.  First,  these  organizations  were 
made  up  of  small  teams;  with  each  team  member  bringing  a  diverse  set  of  skills  to  the 
collaborative  effort.  Precise  data  on  team  size  was  not  collected,  but  indications  are  toward 
project  teams  smaller  than  10.  This  size  easily  facilitates  collaboration,  communication  and 
enables  team  members  to  stay  connected  to  one  another’s  work. 

Second,  these  teams  were  typically  co-located  to  facilitate  face-to-face  interaction  in 
order  to  expedite  problem  solving  and  work.  This  is  not  unusual  in  most  program  or  engineering 
offices,  but  specifically  putting  the  cross-functional  team  members  within  close  proximity,  if  not 
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in  the  same  work  area,  was  a  common  theme.  One  organization  interviewed  felt  that  co-location 
was  so  important;  a  temporary  building  was  acquired  to  co-locate  their  team.  If  co-location  is 
not  possible,  such  as  when  working  with  customers  from  an  operational  unit,  the  organizations 
go  through  great  lengths  to  either  bring  the  customer  to  the  team  or  vice-versa.  Another  common 
method,  particularly  when  a  large  government  contractor  was  involved,  is  to  send  a  government 
team  representative  to  the  contractor  site  for  extended  periods  of  time  to  facilitate 
communication  and  work  flow  on  behalf  of  the  acquiring  organization. 

As  previously  discussed,  successful  teams  are  made  up  of  a  diverse  set  of  people,  all 
offering  a  different  set  of  experiences,  education,  skillsets,  and  perspectives.  But  having  them  on 
the  team  is  not  enough  -  they  must  work  together  and  collaborate  to  accomplish  some  common 
goal.  Co-location  of  small  teams  is  proven  in  these  organizations  as  an  effective  method  in 
creating  synergies  amongst  the  team  members,  and  providing  a  constant  interactive  environment 
for  the  program  workflow. 

Principle  7:  Work  to  Capture  the  Intent  of  DoDI  5000.02 

•  Tailor  the  acquisition  and  system  engineering  process  to  the  product 

•  Establish  a  clear  and  short  approval  chain 

•  Document  what  is  important  and  decisions  made  -  not  much  else 

•  Use  various  contracting  vehicles  to  accomplish  different  tasks 

It  may  appear  to  the  casual  viewer  that  these  rapid  organizations  are  the  “Wild  West”  of 
the  DoD  acquisitions  community.  However,  solid  acquisition  and  engineering  approaches  to 
solving  complex  technical  problems  and  fulfilling  real  operational  needs  were  consistently 
observed.  Because  of  the  specialized  nature  of  each  office,  many  have  developed  in-house 
processes  adaptable  to  each  new  program.  This  ensures  each  program  office  has  a  specific 
roadmap  leading  it  to  success,  and  each  project  lives  within  its  own  specific  process  and  lifespan. 
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In  the  interest  of  time,  these  organizations  ensure  every  acquisition  or  SE  process  they 
implement  is  tailored  to  the  product.  Anything  not  required,  deemed  unnecessary,  or  found  to  be 
non-value  added  is  set  aside.  Adhering  to  the  full  intent  of  DoDI  5000.02,  they  apply  it  to  their 
specific  product  without  excess.  It  may  appear  these  organizations  are  skipping  steps  in  the 
acquisition  process.  The  research  indicates  these  steps  are  not  skipped,  but  rather  tailored  to 
meet  the  stringent  timelines  required  to  deliver  product  to  the  warfighter.  For  example,  a 
Systems  Engineering  Plan  (SEP)  may  consist  of  only  two  pages  within  a  higher  level  document, 
instead  of  a  30  page  stand-alone  file.  They  use  formal  and  infonnal  review  processes, 
specifically  milestone-type  reviews,  with  the  right  people  in  attendance  to  make  go/no-go 
decisions  on  the  spot.  The  focus  is  to  document  important  technical  and  programmatic 
information  and  critical  decisions.  There  are  no  documents  produced  for  documentation  sake. 

In  interviewing  some  organizations,  it  became  evident  their  approval  chain  for  reviews 
and  program  milestone  approval  had  been  shortened.  Additionally,  the  approval  chains  were 
clearly  defined.  In  most  of  these  organizations,  there  are  very  few  extraneous  persons  in  the 
review  chain  that  do  not  have  some  sort  of  approval  authority  or  intrinsic  value  added  (such  as 
legal  or  contracting). 

The  brevity  of  these  approval  chains  often  stems  from  a  Program  Management  Directive 
(PMD)  outlining  the  decision  making  authority  within  these  organizations.  This  document  can 
outline  specific  positions  with  approval  authority,  typically  pushing  it  down  to  a  lower  level  of 
responsibility  within  the  organization,  shortening  the  approval  chain  and  reducing  the  time 
required  to  make  programmatic  decisions.  Some  of  this  brevity  may  also  stem  from  the 
classification  level  of  the  project,  literally  preventing  some  personnel  from  participating. 
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Finally,  program  size  may  keep  budgets  under  Major  Defense  Acquisition  Program  (MDAP) 
thresholds. 

An  often  frustrating  part  of  the  acquisition  process  is  bureaucracy.  Interviewees 
indicated  that  occasionally  some  individuals  believe  they  need  to  be  part  of  a  review  process 
ostensibly  because  of  their  position,  leadership  or  not,  which  can  become  a  road  block  for  the 
program  team.  Conversations  reveal  this  behavior  may  be  caused  by  personal  agendas,  need  for 
a  feeling  of  empowerment  or  importance,  or  simply  because  the  process  has  always  been  done  a 
certain  way.  In  rapid  programs,  if  someone  does  not  have  value  to  add,  they  are  not  included. 
This  was  not  to  the  exclusion  of  participation,  but  value  added  by  personnel  directly  or  indirectly 
involved  in  the  process  is  critically  analyzed.  This  analysis  helps  avoid  the  pitfall  of  people 
merely  adding  time  to  the  process  and  pushing  back  on  the  review  process  without  bona  fide 
authority  to  do  so. 

Another  practice  is  to  combine,  not  skip,  program  level  reviews.  For  example,  test  plans, 
Technical  Readiness  Review  Boards  (TRRB),  Safety  Review  Boards  -  if  deemed  low  risk,  can 
be  signed  off  at  the  local  level  in  a  single  review.  This  is  also  applied  to  pre-milestone  decision 
reviews  as  well.  This  concept  does  not  indicate  system  engineering  processes  and  thoroughness 
are  brushed  aside.  The  approach  is  to  shorten  the  approval  and  review  process  timeline  by 
combining  review  processes  and  reducing  the  lull  created  by  waiting  for  a  review  process  to  take 
place  -  not  to  diminish  the  quality  of  the  product  or  eliminate  SE  analysis  processes. 

Another  common  trend  is  the  use  of  various  contracting  vehicles  to  accomplish  different 
tasks,  some  of  which  are  in  place  for  several  years,  for  use  when  needed  or  to  provide  frequently 
used  specific  services.  Indefinite  Delivery  Indefinite  Quantity  (IDIQ)  contracts  were  important 
to  several  organizations  to  provide  as-needed  support  on  a  reoccurring  basis.  This  approach 
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requires  a  special  type  of  contracting  capability,  referred  to  by  one  organization  as  “creative 
contracting”.  This  can  only  be  done  by  contracting  officers  who  are  willing  to  investigate  the  art 
of  contracting  -  discover  how  something  could  be  put  on  contract  in  a  way  most  advantageous  to 
the  product  and  program  situation — all  within  the  bounds  and  utilizing  the  full  flexibility  of  the 
Federal  Acquisition  Regulation  (FAR). 

Principle  8:  Designing  out  All  Risk  Takes  Forever... Accept  Some  Risk  of  Failure 

•  Creative  (and  implementable)  solutions  are  allowed 

•  Mitigate  risk  through  the  use  of  mature  and  proven  technology 

•  Potential  for  failure  is  accepted,  because  providing  something  may  be  better  than  nothing 

•  Detennine  the  level  of  risk  the  customer  is  willing  to  accept 

The  organizations  interviewed  operate  under  an  uncommon  risk  paradigm  when 
compared  to  many  large  DoD  acquisition  programs.  In  rapid,  the  potential  for  “failure”  through 
providing  only  a  partial  or  short  tenn  solution  to  the  field  may  be  acceptable,  as  this  may  be 
preferable  to  delivering  nothing  at  all.  These  teams  are  made  up  of  technical  experts  who 
cognitively  assess  the  risks  of  different  technical  solutions  throughout  the  design  process, 
sometimes  with  formal  risk  assessment  processes  in  place.  This  idea  of  risk  mitigation  through 
use  of  mature  and  proven  technology  led  several  programs  to  adopt  the  concept  of 
demonstrations  or  prototyping  versus  modeling  as  a  better  use  of  time  and  resources.  The 
bottom  line  often  came  down  to  the  level  of  program  or  technical  risk  the  customer  is  willing  to 
accept — emanating  from  detailed  conversations  with  the  customer.  If  the  warfighter  could 
utilize  a  partial  solution  and  is  willing  to  take  some  technical  risks  with  a  prototype  in  the  field, 
delivery  times  are  considerably  shortened  and  feasible  solutions  can  be  arrived  at  allowing 
testing  in  the  field  and  real-world  feedback  for  incremental  improvements. 

According  to  Merriam-Webster’s  dictionary,  “create”  is  defined  as:  To  produce  through 
imaginative  skill  (Merriam-Webster,  2012).  While  thinking  creatively  is  not  necessarily 
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commonplace  in  everyday  acquisition,  in  rapid  acquisition  it  is  absolutely  acceptable  and  quite 
often  critical  to  success.  Creative  and  implementable  solutions  must  be  sought  in  order  to  do 
things  rapidly.  Some  of  this  success  hinges  on  expert  understanding  of  the  design  space, 
potential  technical  solutions,  and  the  ability  to  integrate  existing  technologies.  Rapid  programs 
work  through  a  rigorous  design  process,  working  to  identify  and  eliminate  risks.  However, 
attempting  to  design-out  all  risk  is  a  time  consuming  and  costly  process,  and  not  realistic  if 
attempting  to  get  a  solution  out  to  the  customer  quickly. 

Principle  9:  Keep  an  Eye  on  “Normalization” 

•  Track  your  technical  debt 

•  Do  configuration  management,  even  if  it  is  in  your  engineer’s  head 

•  Buy  or  maintain  data  rights  or  a  build-to  spec 

“Normalization”  is  a  term  heard  at  one  of  the  larger  DoD  rapid  acquisition  offices,  but  the 

concept  was  reoccurring.  It  essentially  describes  the  transition  of  a  program  from  a  prototype  or 

rapid  project  into  a  major  acquisition  program  or  into  some  fonn  of  mass  production.  Most  of 

the  organizations  interviewed  typically  work  in  small-rate  production  runs  (a  few  to  less  than 

15).  Thus,  the  investments  required  for  product  implementation  are  minimal  compared  with  a 

large  aircraft  program  predestined  for  a  full  rate  production  phase  and  years  of  sustainment. 

However,  as  many  rapid  projects  have  the  potential  to  become  normalized,  it  is  advantageous  for 

these  offices  to  keep  their  eyes  on  this  possibility  and  be  prepared  for  a  transition  to  happen. 

Technical  debt,  another  term  heard  at  one  of  the  organizations,  is  a  concept  coined  by 

Mark  Cunningham  in  the  early  1990’s  as  a  way  to  describe  the  risks  and  compromises  made  in 

rapid  development.  He  first  applied  the  concept  to  software  development: 

“Shipping  first  time  code  is  like  going  into  debt.  A  little  debt  speeds  development  so  long 
as  it  is  paid  back  promptly  with  a  rewrite...  The  danger  occurs  when  the  debt  is  not 
repaid.  Every  minute  spent  on  not-quite-right  code  counts  as  interest  on  that  debt.  Entire 
engineering  organizations  can  be  brought  to  a  stand-still  under  the  debt  load  of  an 
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unconsolidated  implementation,  object-oriented  or  otherwise.”  (Cunningham,  The 
WyCash  Portfolio  Management  System,  1992) 

Mr.  Cunningham  has  recently  commented  that  this  concept  has  been  misinterpreted  and  confused 
with  the  idea  that  you  can  do  sloppy  or  poor  work  up  front  with  the  intention  of  doing  a  good  job 
later.  (Cunningham,  Debt  Metaphor,  2009).  That  is  not  the  case  with  the  rapid  organization 
whose  primary  purpose  is  to  provide  useful  products  to  the  warfighters  in  the  field.  Providing  a 
poorly  executed  product  to  the  field,  however  rapidly,  would  quickly  render  these  organizations 
useless. 

The  technical  debt  concept  allows  these  organizations  to  move  forward  quickly,  before 
they  may  fully  understand  the  problem,  all  the  while  tracking  what  has  been  assumed  or  skipped 
in  the  design,  engineering,  and  systems  management  realm.  The  importance  of  tracking  these 
processes  comes  into  play  as  the  program  matures;  particularly  if  the  program  is  successful  and 
is  normalized  into  a  larger  military  procurement  program  or  new  program  of  record.  If  these 
processes  or  analyses  are  not  tracked,  it  will  be  difficult  to  know  what  work  might  need  to  be 
completed  as  the  program  moves  into  traditional  maturity.  For  example,  on  a  small-scale  small- 
shop  project,  configuration  management  may  have  been  done  in  the  engineer’s  head.  However, 
if  there  is  a  desire  to  mass  produce  an  item,  configuration  management  and  a  true  product 
baseline  will  be  needed.  Knowing  what  systems-level  work  has  or  has  not  been  accomplished  is 
critical  to  successful  transition  to  a  normalized  and  potentially  mass  produced  product. 

This  concept  also  confirms  a  popular  topic  amongst  all  acquisition  and  engineering 
programs — data  rights.  Many  of  these  organizations  specifically  mentioned  the  benefits  of 
purchasing  or  maintaining  some  level  of  government  owned  data.  The  level  of  data  required 
varies  between  programs,  but  the  intent  was  consistent:  Have  enough  data  to  provide  the  ability 
to  modify  when  necessary,  maintain  competition,  and  easily  transition  toward  nonnalization. 
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PRODUCT 


Principle  10:  Use  Mature  Technology  -  Focus  on  the  State  of  the  Possible 
Principle  11:  Incremental  Development  is  Part  of  the  Product  Plan 
Principle  12:  Smaller  Budgets  Receive  Less  Oversight  and  are  More  Stable 


Principle  10:  Use  Mature  Technology  -  Focus  on  the  State  of  the  Possible 

•  Focus  on  integration  of  mature  technologies 

•  Reuse  existing  capabilities,  platforms,  etc.  -  especially  if  they  are  flight-certified 

In  rapid  acquisition,  untested  and  unproven  technology  poses  an  enormous  risk  to  system 
success.  Unlike  most  traditional  acquisition  programs,  there  is  no  time  for  technology  to  mature, 
in  other  words,  no  time  for  schedule  slips  due  to  immature  technology  struggling  to  develop.  To 
avoid  this  pitfall,  most  rapid  programs  focus  engineering  efforts  on  the  interfaces  required  to 
blend  multiple  existing  technologies  into  a  system  capable  of  providing  the  desired  set  of 
capabilities.  Another  aspect  of  rapid  is  modifying  an  existing  platfonn  or  simply  adding 
subsystems  and  components.  Program  teams  stay  abreast  of  emerging  technology  and  leverage 
the  work  done  by  industry  and  other  military  programs.  They  then  engineer  a  system-of-systems 
solution  to  meet  requirements.  This  bounds  their  design  space  within  the  state  of  the  possible  - 
that  has,  in  part,  already  been  proven.  In  Technology  Readiness  Level  (TRL)  terms,  this  means 
nothing  less  than  a  TRL  6,  preferably  7  or  8.  This,  in  combination  with  the  concepts  of  reuse  and 
incremental  development,  allow  these  teams  to  field  quickly,  but  generationally  provide  more 
and  more  capability. 

In  many  cases,  the  urgent  need  requests  are  to  satisfy  a  newly  emerged  operational 
requirement.  These  organizations  perfonn  an  abbreviated  analysis  of  alternatives  (AoA)  to 
determine  how  best  to  meet  that  need.  By  the  time  the  request  arrives  at  one  of  these 
organizations,  current  technical  capabilities  indicate  a  materiel  solution  can  be  developed  for  the 
warfighter.  Often  times,  the  concept  of  delivering  a  partial  solution  is  driven  not  only  by  time, 
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but  also  by  technical  maturity.  While  a  laboratory  may  have  proven  that  something  is  feasibly 
possible,  its  use  in  the  battlefield  is  several  years  away.  However,  by  leveraging  existing 
components  and  integrating  them  in  a  new  or  innovative  way,  these  organizations  are  able  to 
provide  an  equivalent  or  interim  solution  in  short  order.  In  this  environment,  the  warfighter  is 
given  something  to  use  now,  and  as  technology  matures,  they  can  expect  greater  capability  in  the 
future. 

Another  essential  characteristic  of  rapid  product  development  is  the  reuse  of  existing 
technical  capabilities.  This  is  further  improved  when  existing  technical  capabilities  are 
integrated  onto  existing  platfonns.  A  great  example  is  a  recent  modification  one  organization 
performed  to  improve  a  small  fleet  of  Combat  Search  and  Rescue  (CSAR)  helicopters.  Rather 
than  develop  a  new  forward  looking  infrared  radar  (FLIR)  pod  or  lift  hoist,  the  team  examined 
the  operational  requirements  requested  by  the  user  and  identified  existing  technology  currently 
being  installed  by  the  US  Army  on  Department  of  State  and  Federal  Bureau  of  Investigation 
helicopters.  This  reuse  approach  saved  the  program  office  over  half  of  the  potential  contracted 
price  (about  $3M  saved)  and  12  months  of  schedule.  In  addition,  the  customer  also  received  a 
Government-owned  technical  data  package  (TDP)  because  the  design  and  engineering  work  was 
done  in-house. 

Another  significant  reduction  in  time  for  this  example  was  the  time  saved  in  flight  test  by 
using  equipment  that  had  already  been  flight-certified.  This  approach  created  huge  efficiencies 
in  their  flight  test  program  as  many  of  the  test  requirements  had  already  been  accomplished  by  a 
previous  program. 

Principle  11:  Incremental  Development  is  Part  of  the  Product  Plan 

•  "Generational  development"  -  plan  for  technology  maturity,  advancement,  and  cycles 

•  Look  for  unpredicted  outcomes 
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Part  of  the  agreement  of  accepting  a  partial  solution  may  also  include  the  plan  for 
incremental  development.  When  this  concept  is  decided  upon  from  the  beginning  of  any 


development  program,  it  enables  "generational  development"  -  an  intentional  plan  for 
technology  maturity,  advancement,  and  cycles  of  growth.  This  may  be  done  by  using  open 
architectures,  modular  concepts,  clearly  defining  system  interfaces,  and  utilizing  industry 
standards.  When  planning  for  incremental  growth  in  platform  capabilities  from  the  start, 
particular  systems  level  planning  is  put  into  place.  This  approach  allows  known  or  unknown 
technical  improvements  to  be  more  easily  integrated  into  the  baseline  system — providing  faster 
upgrading  and  an  enhanced  ability  to  share  system  level  data.  Overall,  this  approach  will  extend 
the  system  lifecycle  and  enhance  its  ability  to  flexibly  meet  the  needs  of  an  ever  changing 
technical  and  operational  environment. 

Finally,  as  these  organizations  march  through  their  development  programs,  many  are 
constantly  looking  for  unpredicted  design  outcomes.  In  one  organization,  during  the  latter  stages 
of  product  development  a  specific  set  of  questions  were  asked:  Who  else  could  use  this?  How 
else  could  it  be  used?  What  does  this  enable  next?  How  could  this  be  used  against  us?  This 
series  of  questions  put  this  team  in  the  right  mindset  to  further  the  development  and  utilization  of 
their  products. 

Principle  12:  Smaller  Budgets  Receive  Less  Oversight  and  are  More  Stable 

•  Budget  size  may  become  its  own  enemy 

•  Rapid  funding  is  typically:  Assured,  from  various  sources,  and  may  require  recoloring 

Budgets  are  often  thought  of  as  a  process  principle,  but  it  depends  on  the  context.  One 

benefit  many  of  the  rapid  program  offices  enjoy  is  a  lack  of  size.  When  you  are  to  move  fast, 
smaller  is  often  better.  Not  only  do  large  organizations  create  challenges  to  effective 
management  and  full  utilization  of  all  personnel  resources,  they  tend  to  have  larger  budgets.  Big 
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programs  and  big  budgets  can  easily  become  targets  for  increased  oversight,  longer  approval 
chains,  and  funding  cuts.  In  this  sense,  being  big  creates  its  own  problems.  Size  becomes  its 
own  enemy. 

In  this  research,  the  size  of  the  program  budgets  appeared  directly  related  to  the  products 
themselves.  The  design  and  technologies  selected  to  meet  operational  requirements  directly 
impact  the  cost  of  the  program.  Sub-system  product  selection,  interface  complexity,  sustainment 
considerations,  and  technical  maturity  all  drive  cost.  Keep  in  mind  these  organizations  are 
focusing  on  the  23-80%  solution,  are  not  going  into  mass  production,  and  are  not  necessarily 
planning  for  long-term  sustainment.  They  are  also  not  developing  $300M  fighter  jets.  However, 
these  organizations  intentionally  take  steps  to  reduce  the  overall  size  of  their  budgets.  For 
example,  the  willingness  to  accept  some  types  of  risk  buys  down  the  cost  of  the  design, 
development  and  manufacturing  efforts.  Costs  (and  risk)  are  also  reduced  by  using  proven  or 
mature  technology.  Utilizing  simple  or  standard  interfaces  can  help  reduce  complexity — 
reducing  development  costs. 

As  with  contracting  officers,  many  rapid  organizations  have  dedicated  finance  personnel 
who  work  to  manage  the  cornucopia  of  funding  sources  for  these  projects.  Imagine  the  variety 
of  funding  types  coming  into  an  organization  that  executes  projects  for  all  military  branches, 
several  3-letter  government  agencies,  and  foreign  military  sales.  These  organizations  rely  on  the 
flexibility  of  multiple  funding  types.  Some  customers  come  to  them  with  a  need,  but  arrive  with 
funding  from  various  sources  or  not  the  right  color  of  money.  It  takes  a  special  kind  of 
organization  and  finance  officer  to  understand,  acquire  and  execute  these  funds. 
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Conclusion 


Data  Analysis 

In  conclusion,  we  hypothesized  rapid  acquisition  organization  success  is  governed  by  a 
common  set  of  principles  and  that  via  interview  sessions  with  these  organizations,  common 
governance  would  emerge.  Through  our  analysis,  a  common  set  of  principles  did  emerge  and 
attempts  are  already  being  made  to  apply  some  of  them  to  traditional  acquisition  programs. 

Table  2.  Principle/Concept  Occurrence  in  Interviews 


Principle 

Title 

#  of  Times  Cited 

1 

Build  and  Maintain  Trust 

46 

2 

Populate  Your  Team  with  Specific  Skills 

53 

3 

High  Fevels  of  Motivation  and  Expectations 

24 

4 

Government  Team  Eeads  the  Way 

12 

5 

Defined  Set  of  Stable  Requirements 

46 

6 

Small  Co-Focated  Teams 

30 

7 

Intent  of  DoDI  5000.02 

57 

8 

Designing  out  All  Risk  Takes  Forever 

17 

9 

Keep  an  Eye  on  “Normalization” 

9 

10 

Use  Mature  Technology 

47 

11 

Incremental  Development 

23 

12 

Smaller  Budgets  Get  Fess  Oversight 

5 

Total  Citations  369 


While  each  organization  interviewed  was  unique  in  the  products  produced  and  the  processes 
used  to  produce  them,  research  saw  several  significant  and  common  themes  emerge  from  the 
data.  Table  2  shows  the  number  of  times  a  specific  principle  was  materially  brought  up  or  cited 
as  a  significant  business  practice  in  the  interviews.  This  lends  to  a  “top  5”  list  of  most  significant 
attributes  of  rapid  organizations,  comprising  67%  of  our  data  points. 


Top  5  List 

1 .  Work  to  Capture  the  Intent  of  DoDI  5000.02 

2.  Populate  Your  Team  with  Specific  Skills  and  Experiences 

3.  Use  Mature  Technology  -  Focus  on  the  State  of  the  Possible 

4.  Defined  Set  of  Stable  Requirements  Focused  on  Warfighter  Needs 

5.  Build  and  Maintain  Trust 
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Further  qualitative  data  analysis  shows  co-occurrences  (i.e.  correlations)  between  several 
principles.  Patterns  emerged  showing  co-occurrences  of  principles  to  one  another  based  on  their 
appearance  together  in  the  data  set.  For  example,  analysis  showed  the  principle  “populating  your 
team  with  specific  skills  and  experiences”  frequently  occurring  with  the  principle  “build  and 
maintain  trust”.  In  fact,  the  strongest  co-occurrences  appeared  between  four  of  the  “Top  5” 
principles  and  “Small  Co-located  Teams”.  Of  the  top  five,  only  “Use  Mature  Technology”  did 
not  show  strong  co-occurrence  values  with  the  other  principles. 

These  results  are  somewhat  intuitive.  As  can  be  seen  in  Appendix  D,  people  principles 
most  frequently  co-occurred  with  other  principles.  This  implies  the  principles  that  define  the 
people  on  a  team  drive  the  overall  perfonnance  of  the  effort.  If  organizations  have  the  right 
people  supporting  a  program,  it  appears  they  are  more  likely  to  keep  process  where  needed  and 
get  the  right  product  delivered.  Significant  co-occurrence  with  regards  to  product  is  centered  on 
stable  requirements  and  incremental  development.  Drilling  down  into  these  two  principles,  we 
conclude  a  better  product  emerges  with  stable  and  well  defined  requirements  in  an  incremental 
development  plan.  Strong  process  principle  co-occurrences’  links  back  to  utilizing  people 
through  small  co-located  teams.  In  addition,  conceptually  working  through  standard  DoDI 
5000.02  processes  with  well  defined  requirements  created  the  core  of  most  rapid  programs. 
Supposition 

A  set  of  stable  requirements  is  a  must  for  any  program,  but  even  more  so  in  an 
environment  where  time  is  of  the  essence.  Focusing  on  what  is  considered  necessary  to  get  the 
mission  done  versus  what  may  be  “wanted”  is  equally  critical  to  quickly  putting  something  in  the 
field.  Also  observed  were  unique  environmental  attributes  helping  to  optimize  the  program 
management  process.  Small,  empowered  teams  centrally  located  in  the  same  facility  helped  to 
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enhance  cooperation,  communication  and  productivity.  These  teams,  formed  of  the  right  mix  of 
highly  competent  personnel,  made  accomplishing  the  mission  in  rapid  form  a  possibility.  From  a 
process  perspective,  shortened  approval  chains  stemming  from  classification  of  the  program  or 
PMD’s  granted  at  DoD  levels  greatly  reduced  time  spent  acquiring  go/no-go  decisions.  Further, 
tailoring  approval  for  DoDI  5000.02  specified  documentation  reduces  paperwork,  approval 
processes,  and  redundant  staffing. 

From  an  engineering  perspective,  researchers  observed  very  few  “cannot  fail”  programs. 
Rather,  these  programs  were  “must  succeed”  for  the  sake  of  the  warfighters  fighting  the  current 
fight.  This  is  enhanced  by  the  utilization  of  mature  technology,  but  also  enabled  by  the 
entrepreneurial  spirit  of  these  organizations  where  creative  thinking  and  strategic  risk  taking 
were  allowed.  Finally,  while  there  may  be  some  nontraditional  engineering  practices  observed, 
these  organizations  took  very  seriously  the  brevity  with  which  they  were  executing  processes. 
Through  one  method  or  another,  organizations  focused  on  what  was  absolutely  necessary  to 
accomplish  the  design,  test  and  build  processes,  all  the  while  tracking  what  would  have  been 
done  if  more  time  was  available. 

With  so  many  rapid  offices  in  existence,  it  may  seem  rapid  is  becoming  “normal”.  Air 

Force  senior  leaders  have  publically  acknowledged  the  benefits  of  utilizing  these  methods.  In 

recent  remarks,  AF  Secretary  Michael  Donley  discussed  the  new  bomber  program. 

“In  contrast  to  the  previous  Next  Generation  Bomber  program,  this  long-range  bomber 
will  leverage  mature  technologies  to  deliver  on-schedule  and  in  sufficient  quantity  before 
the  current  fleet  ages  out.  We  will  constrain  requirements,  lower  technical  risk,  put  more 
emphasis  on  affordability,  and  use  an  established,  streamlined  model  for  program 
management  and  oversight.”  (Donley,  2011) 
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Further,  the  Air  Force  announced  that  its  Next  Generation  Bomber  will  be  managed  “in  a 
streamlined  fashion”  under  the  auspices  of  the  Rapid  Capabilities  Office  (Reed,  2012),  one  of  the 
organizations  interviewed  for  this  research. 

The  processes  and  practices  applied  to  meeting  urgent  needs  must  generate  innovative 
conceptual  solutions,  quickly  truncate  the  design  space,  and  choose  good  designs  that  can  deliver 
warfighting  capability  as  fast  as  technically  possible.  The  processes  and  practices  applied  to 
urgent  needs  programs  must  add  value  and  not  require  an  excessive  bureaucratic  oversight  to 
implement,  while  at  the  same  time  address,  understand,  and  manage  program  and  technical  risk. 
It  is  the  overall  intent  of  this  guidebook  to  present  these  principles  as  an  analysis  of  how  rapid 
organizations  conduct  their  business:  Who  is  selected  to  work  in  these  organizations,  how  they 
make  key  programmatic  and  system  engineering  decisions,  and  what  drives  the  selection  of 
technology  used  to  meet  the  operational  needs  of  warfighters.  Equipped  with  these  principles, 
traditional  acquisition  programs  may  have  opportunities  to  consider  another  way  of  doing 
business  in  hopes  a  new  approach  may  help  solve  problems  experienced  on  programs  of  a  larger 
scale. 
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Appendix  A:  Establishing  a  Debrief  Culture 

Many  concepts  can  be  borrowed  from  the  strong  debrief  culture  of  tactical  military 
aviation,  where  the  debrief  is  an  environment  in  which  team  members  can  speak  freely  without 
reprisal  and  constructive  criticism  is  expected  by  all.  In  flying  organizations,  the  platitude 
“there’s  no  rank  in  the  debrief’  is  often  used  to  describe  the  debrief  environment — accentuating 
that  everyone’s  equal  contribution  and  the  mission  is  greater  than  the  individual  and  their  pride. 
The  debrief  is  a  sacred  environment  oriented  towards  the  mission  itself  and  not  the  specific 
perfonnance  of  one  particular  team  member.  The  debrief  culture  must  be  established  at  the  top- 
level  of  the  organization.  Leadership  must  outline  and  enforce  the  expectations  and  importance 
of  the  debrief  process,  compelling  team  members  to  expect  a  focused  debrief  culture.  The  correct 
culture  stresses  determining  root  causes  and  lessons  learned  to  better  the  organization  rather  than 
personal  attacks  on  individuals.  With  the  right  expectations,  team  members  can  then  focus  on 
improving  with  the  assumption  that  no  project  is  ever  perfect. 

An  effective  project  debrief  is  enabled  by  a  structured,  expected  format  and  mediated  by 
a  member  of  the  project  leadership,  such  as  the  Program  Manger.  The  debrief  process  begins 
with  fonning  of  objectives  at  the  start  of  the  project,  which  will  be  used  to  develop  Debrief 
Focus  Points  (DFPs)  during  the  debrief.  Objectives  should  be  tailored  to  the  specific  project  and 
may  incorporate  project  requirements,  cost  and  timeline.  The  debrief  lead  detennines  if  a  DFP  is 
present  by  comparing  the  actual  outcome  of  the  project  to  the  expected  outcome  and  objectives. 
If  the  expected  and  actual  results  agree  (objectives  are  achieved),  but  the  results  were  achieved  in 
an  unplanned,  unexpected,  or  even  improper  fashion  (raw  luck,  for  example,  was  the  only  reason 
things  went  well),  then  a  DFP  may  still  be  present. 
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Once  DFPs  have  been  determined,  the  debrief  lead  must  then  work  to  find  the  cause.  The 
causes  for  DFPs  can  be  titled  Contributing  Factors  (CFs).  A  CF  is  a  potential  explanation  for 
why  a  DFP  occurred.  Each  DFP  may  have  one  or  more  CFs.  The  debrief  lead  may  begin  the 
debrief  with  several  obvious  CFs  already  in  place,  and  then  during  focused  review  of  the  project 
with  all  team  members,  develop  more  CFs.  After  the  focused  review  of  the  project  and 
detennination  of  all  CFs,  the  emphasis  should  be  placed  on  determining  fixes  for  each  CF  as 
applicable,  and  finally  identifying  which  CFs  are  the  Root  Cause  (RC)  for  each  DFP.  The  end- 
state  of  the  debrief  is  the  development  of  Lessons  Learned  that  incorporate  the  RC  for  each  DFP 
in  pointed,  clearly-written  statements  to  be  catalogued  and  referenced  for  future  projects.  There 
may  be  a  need  to  conduct  intennediate  debriefs  at  specific  project  phases  on  longer  projects 
depending  on  the  scope  of  the  organization  and  each  project. 
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Appendix  B:  Rapid  Acquisition  Principles 


PEOPLE 


Principle  1:  Build  and  Maintain  Trust 

•  Develop  solid  relationships  and  work  to  maintain  them 

•  Empowered  leadership 

•  Autonomy  for  Program  Managers/Engineers 

•  Consistent  customer  input  &  buy-in  every  step  of  the  way 

Principle  2:  Populate  Your  Team  with  Specific  Skills  and  Experience 

•  Hand  pick  your  team. . . or  grow  your  own 

•  Acquire  people  with  the  right  education,  experience,  and  personality 

•  Build  the  right  team  for  each  project 

Principle  3:  Maintain  High  Levels  of  Motivation  and  Expectations 

•  Motivation  and  mindset:  Collaborative,  competitive,  impatient,  creative,  technical, 
tangible  results,  independent 

•  Mistakes  are  OK,  but  it  is  not  OK  to  repeat  them 

•  Every  member  connected  to  the  mission  and  vision 

Principle  4:  The  Government  Team  Leads  the  Way 

•  High  level  of  expectations  for  government  personnel  (military  and  civilian)  to  run 
programs 

•  Focus  on  full  use  of  government  personnel  capabilities  -  technical  competence  is 
expected 

PROCESS 


Principle  5:  Defined  Set  of  Stable  Requirements  Focused  on  Warfighter  Needs 

•  Get  the  requirements  right— everything  you  do  stems  from  them! 

•  Capability  based  requirements  rooted  in  customer  derived  “CONOPS” 

•  Use  solid  systems  engineering  (SE) 

•  Expedite  trade  studies  -  then  make  a  decision  and  press  forward 

•  Focus  on  providing  the  23-80%  solution 

Principle  6:  Small  Co-Located  Teams 

•  Small  teams  with  the  right  skill  sets  to  solve  the  problem 

•  Co-located  workspace  and  facilities 

Principle  7:  Work  to  Capture  the  Intent  of  DoDI  5000.02 

•  Tailor  the  acquisition  and  system  engineering  process  to  the  product 

•  Establish  a  clear  and  short  approval  chain 

•  Document  what  is  important  and  decisions  made  -  not  much  else 

•  Use  various  contracting  vehicles  to  accomplish  different  tasks 
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Principle  8:  Designing  out  All  Risk  Takes  Forever... Accept  Some  Risk  of  Failure 

•  Creative  (and  implementable)  solutions  are  allowed 

•  Mitigate  risk  through  the  use  of  mature  and  proven  technology 

•  Potential  for  failure  is  accepted,  because  providing  something  may  be  better  than  nothing 

•  Detennine  the  level  of  risk  the  customer  is  willing  to  accept 

Principle  9:  Keep  an  Eye  on  “Normalization” 

•  Track  your  technical  debt 

•  Do  configuration  management,  even  if  it  is  in  your  engineer’s  head 

•  Buy  or  maintain  data  rights  or  a  build-to  spec 

PRODUCT 


Principle  10:  Use  Mature  Technology  -  Focus  on  the  State  of  the  Possible 

•  Focus  on  integration  of  mature  technologies 

•  Reuse  existing  capabilities,  platforms,  etc.  -  especially  if  they  are  flight-certified 

Principle  11:  Incremental  Development  is  Part  of  the  Product  Plan 

•  "Generational  development"  -  plan  for  technology  maturity,  advancement,  and  cycles 

•  Look  for  unpredicted  outcomes 

Principle  12:  Smaller  Budgets  Receive  Less  Oversight  and  are  More  Stable 

•  Budget  size  may  become  its  own  enemy 

•  Rapid  funding  is  typically:  Assured,  from  various  sources,  and  may  require  recoloring 
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Appendix  C:  RT-34  Interview  Questions 

1.  Process  (Systems  engineering  methods,  processes,  and  tools) 

a.  Do  you  use  standard/  formal  SE  processes  in  your  rapid  development  organizations? 
Which  ones? 

b.  Are  SE  processes  tailored  for  each  program  or  product.  If  so,  which  ones  can  be 
highly  tailorable  and  why 

c.  How  are  SE  methods,  processes  and  tools  different  based  on  project  scale/  scope 

d.  What  level  of  risk  is  acceptable,  how  do  you  determine  that,  and  how  do  you 
systemically  address  it  at  all  levels 

e.  What  is  the  fonnality  of  engineering  documentation 

f.  How  replicable  /  transferable  are  your  processes  from  one  project  or  product  to 
another 

g.  How  do  model-based  systems  engineering  approaches  support  your  rapid 
development 

h.  Do  you  integrate  a  variety  of  models/  simulations/  prototypes  early  in  the  lifecycle, 
and  if  so,  how 

i.  How  would  you  describe  your  ability  to  be  innovative  in  concept  refinement 

j .  What  are  best  practices  for  problem  domain  understanding 

k.  How  do  you  manage  scope  and  requirements 

l.  What  infrastructure  (tools,  modeling  &  sim)  allows  continuously  quickening  product 
delivery  cycles 

m.  Decision  Analysis  Processes 

i.  Who,  and  at  what  level,  are  most  engineering  decisions  made 

ii.  Who  is  empowered,  how  do  they  know  it,  how  are  they  supported 

iii.  To  what  extent  are  major  decisions  documented,  formalized,  communicated 

iv.  How  do  you  prepare  for  major  decisions 

2.  People  (including  Team  Collaboration) 

a.  What  types  of  teams  do  you  use  (e.g.,  domain,  functional,  IPT,  etc) 

b.  What  are  the  primary  leadership  roles  for  an  expedited  project  or  for  the  best  projects 
that  run  the  most  efficiently  (program  or  project  manager,  chief  engineer,  chief 
architect,  etc) 

c.  How  do  you  select/  design  the  team 

d.  What  are  the  primary  skills  you  seek  for  the  team 

e.  How  do  you  effectively  incorporate/involve  the  end  user 

f.  How  do  you  effectively  and  continuously  incorporate  the  user  perspective 

g.  How  do  you  manage  and  network  people  and  teams  that  are  not  co-located 

h.  What  role  does  collaboration  play. . .  in  management,  in  team  building,  in  problem 
solving,  in  SE  processes,  and  in  geographically  distributed  teams 

i.  How  do  you  facilitate  improved  collaboration  (internal,  external) 
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j .  What  collaborative  tools  or  processes  do  you  use 

k.  What  types  of  meetings  do  you  hold,  who  attends,  who  makes  decisions,  and  why 

l.  How  do  you  manage  urgent  project  tempos  and  its  personnel  effects  (stress,  work 
hours,  burnout) 

m.  How  do  you  reduce  complexity  of  the  SE  process 

3.  Product  (Architectural  Design  Considerations) 

a.  How  do  you  translate  prototypes  to  operational  use 

b.  How  long  is  the  intended  operational  lifecycle  of  the  product 

c.  How  many  units  are  you  producing/fielding 

d.  How  does  your  rapid  development  schedule  drive  architectural/  design  choices 

e.  How  does  reuse,  modification  of  existing  systems,  or  using  product  lines  drive 
reduced  schedules 

f.  How  does  the  level  of  complexity  effect  the  product  architecture 

4.  Project  -  How  are  responses  dependent  (scalable)  on  size  of  the  project  (scope,  cost, 
timeline,  risk,  #  people) 
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Appendix  D:  Co-Occurrence  Matrix 


PEOPLE 

PROCESS 

PRODUCT 

Build  and  Maintain 

Trust 

Populate  Team  with 

Specific  Skills 

Maintain  Motivation 

and  Expectations 

Government  Team 

Leads  the  Way 

Defined  Set  of  Stable 

Requirements 

Small  Co-Located 

Teams 

Intent  of  DoD  5000.2 

Designing  out  All  Risk 

Takes  Forever 

Keep  an  Eye  on 

"Normalization" 

Use  Mature  Technology 

Incremental 

Development 

Smaller  Budgets;  Less 

Oversight 

PEOPLE 

Build  and  Maintain  Trust 

6 

1 

2 

8 

4 

4 

0 

0 

0 

0 

0 

Populate  Team  with  Specific  Skills 

6 

0 

1 

1 
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2 

0 

0 

0 

0 

0 

Maintain  Motivation  and  Expectations 

1 

0 

0 

1 

0 

0 

0 

0 

0 

0 

0 

Government  Team  Leads  the  Way 

2 

1 

0 

0 

1 

1 

0 

0 

0 

0 

0 

PROCESS 

Defined  Set  of  Stable  Requirements 

8 

1 

1 

0 

0 

1 

0 

0 

2 

5 

1 

Small  Co-Located  Teams 

4 

10 

0 

1 

0 

0 

1 

0 

0 

1 

0 

Intent  of  DoD  5000.2 

4 

2 

0 

1 

1 

0 

0 

1 

1 

1 

1 

Designing  out  All  Risk  Takes  Forever 

0 

0 

0 

0 

0 

1 

0 

0 

0 

1 

0 

Keep  an  Eye  on  "Normalization" 

0 

0 

0 

0 

0 

0 

1 

0 

1 

0 

0 

PRODUCT 

Use  Mature  Technology 

0 

0 

0 

0 

2 

0 

1 

0 

1 

1 

0 

Incremental  Development 

0 

0 

0 

0 

5 

1 

1 

1 

0 

1 

0 

Smaller  Budgets;  Less  Oversight 

0 

0 

0 

0 

1 

0 

1 

0 

0 

0 

0 
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